Business Analyst Community & Resources | Modern Analyst

Reinventing the Annual Member Survey: A Business Analyst’s Role in Delivering Actionable Insights

Pulkit Singhal — Sun, 25 Jan 2026 02:38:00 GMT

In a competitive and rapidly evolving financial landscape, understanding member needs is vital to maintaining strong relationships and delivering meaningful value. Yet for many institutions, especially those with legacy processes, collecting structured member feedback can be surprisingly underdeveloped. This was the case at the Federal Home Loan Bank of Chicago (FHLBank Chicago), where — despite its extensive engagement with member institutions — the Bank had never before conducted a structured, enterprise-wide Annual Member Survey.

Recognizing the need for a formalized feedback mechanism, the Bank launched an initiative to design and implement its first-ever Annual Member Survey, leveraging Salesforce as the foundational platform. As the Lead Business Analyst, I was responsible for envisioning, architecting, and orchestrating this new capability from the ground up.

This initiative ultimately became a defining example of how strategic business analysis can create net-new organizational capability, not just improve existing processes.

The Challenge: Creating a Strategic Feedback Framework from Scratch

Unlike most process-automation projects, this effort did not begin with an existing workflow to analyze or improve. Instead, the Bank faced a unique challenge:

No prior survey process existed
No historical data or response structures were available to benchmark against
No distribution, tracking, or reporting mechanisms had been established
No governance model existed for how results should be consumed
Stakeholders possessed varying assumptions about what the new survey should accomplish

This meant the project required not only systems expertise but also conceptual design, stakeholder alignment, and strategic framing.

My Role as Lead BA: Designing a New Enterprise Capability

The absence of an existing process meant that Business Analysis would shape the entire direction of the initiative. My responsibilities included defining the business problem, creating the process architecture, establishing data structures, and ensuring Salesforce could support a sustainable and scalable survey model.

1. Establishing the Vision and Framing the Purpose

Through interviews and collaborative workshops with Member Strategy, Sales, Analytics, and Leadership teams, I led discussions to answer foundational questions:

What insights should the Bank gather annually?
How should “member satisfaction” be defined in measurable terms?
What KPIs would create genuine value for leadership?
How should results be tied back to member institutions in Salesforce?

This work produced the Bank’s first Survey Vision and Strategy Framework, guiding all subsequent design decisions.

2. Building the End‑to‑End Survey Workflow in Salesforce

Because no prior workflow existed, I architected a brand‑new process designed around clarity, automation, and scalability:

Designed the survey creation and distribution model
Built logic for survey-to-member linking
Defined the response-collection data structure
Modeled the end‑to‑end visibility lifecycle, including assignment, participation, reminders, and results
Ensured dashboards would give leadership real-time insights

The process not only captured survey responses but also embedded insights directly into the Bank’s member management ecosystem.

3. Translating Ambiguity Into Clear, Actionable Requirements

Given the lack of precedent, requirements had to be derived through deep analysis rather than comparison. I authored:

Detailed user stories
Acceptance criteria
Process maps
Data models
Reporting definitions

This documentation became the foundational blueprint for developers, testers, and end-users — eliminating ambiguity and creating shared understanding.

4. Leading UAT and Validating a New Capability

Because the Bank had never conducted a survey like this, UAT required additional rigor:

I designed test scripts covering every stage of the survey lifecycle
Trained business stakeholders on how to test a process that was entirely new
Triaged defects and clarified user expectations
Ensured the system was intuitive and future-proofed

Through this, the Bank gained confidence not just in the technology, but in the process itself.

5. Supporting Rollout, Adoption, and Governance

Beyond system delivery, I worked closely with:

Member Strategy teams to formalize interpretation of results
Analytics teams to align on scoring and reporting methodologies
Change management teams to ensure smooth onboarding
Salesforce admins to embed long‑term maintainability

This ensured the survey became an annual, repeatable, institution-wide capability—not a one‑off project.

Conclusion: This project shows that Business Analysts are not just process improvers—they are capability creators.By clarifying needs, defining strategy, architecting processes, aligning teams, and ensuring quality, the BA function enabled FHLBank Chicago to establish a powerful new insight mechanism that will shape strategy for years to come.

The Annual Member Survey is now more than a project deliverable.
It is a permanent intelligence asset for the Bank — built on a foundation of Business Analysis leadership.

Field Mapping vs. Canonical Data Model — Which One Wins in Integrations?

Andrii Siryi — Tue, 28 Oct 2025 15:39:00 GMT

When building integrations between systems, one of the first architectural choices you’ll face is how to align data between them.
Two main approaches dominate this conversation: direct field mapping and the canonical data model.
Let’s break them down.

Field Mapping: Simple but Fragile

Field mapping means you connect each field from System A directly to a matching field in System B.
It’s fast to implement and easy to visualize:

Example:
“CustomerName” → “ClientFullName”
“InvoiceDate” → “BillingDate”

Pros:

Quick setup for simple integrations
Easier to debug and understand
Great for 1-to-1 integrations

Cons:

Every new system adds complexity — you end up maintaining dozens of mappings
Any field name or format change breaks the flow
Hard to scale beyond a few connections

This approach is fine for small, stable environments — like syncing data between CRM and ERP once a day.

Canonical Data Model: Structured and Scalable

A canonical model introduces a shared, unified data layer — a kind of “translation dictionary” for your enterprise.
Instead of connecting systems directly, each system maps to the canonical schema.

Example:
System A → Canonical Model → System B
“CustomerName” → “Customer.FullName” → “ClientFullName”

Pros:

Greatly simplifies multi-system integrations
Reduces maintenance costs over time
Makes it easier to add or replace systems

Cons:

Requires more design work upfront
May be overkill for small projects
Needs governance and version control

This approach shines in large ecosystems — where data flows across multiple ERPs, CRMs, or custom apps.

So… Which One to Choose?

If you’re connecting two systems and don’t expect frequent schema changes — use field mapping.
But if your integration landscape is growing and you want to reduce long-term pain — invest in a canonical model early.

Think of field mapping as a shortcut, and the canonical model as a foundation.

The Importance of Operational Decisions

Arash — Tue, 16 Apr 2019 07:35:00 GMT

It may sound routine, but the importance of operational decisions cannot be underestimated. After all, not a day goes by without even the smallest business making dozens, if not hundreds of operational decisions that may affect the bottom line. Elevate these to large scale companies and we are talking thousands, if not millions of actions that impact day-to-day business operations.

So what do we mean by ‘operational decisions’? The dictionary tells us that a decision is a ‘conclusion or resolution reached after consideration’. It is defined as ‘the action or process of deciding something or of resolving a question’.

From this straightforward definition, we might construe that an operational decision must have an outcome based on a procedure that is designed to resolve an everyday or, in most cases, an ‘unexceptional’ occurrence. This can be called the ‘decision logic’.

It is important to point out, however, that there are differences between operational decisions and those that may be viewed as strategic to the business. Operational decisions are often highly structured, repetitive and routine. In other words, you can model them once and then reuse them ad infinitum for hundreds or thousands of every day transactions. For example, an operational decision may consider compliance with state regulations, or the possibility of a fraudulent transaction, or a calculation of taxation, or an exception to a claims process.

This is precisely why operational decisions are very often excellent candidates for automation.

To demonstrate, an operational decision structure typically looks something like this:

Operational Decision structure. It includes the “decision logic”, input data and the conclusion.

The judgement or action to be taken in each case could involve a list, a simple value, a calculation, a configuration, a price, a guideline, and several other routine outcomes. For example, it could be a list of available options for treatment of a patient, or the best prices for upselling and product bundling, or a billing calculation for a customer, or specific procedures and guidelines, and so on.

The bottom line is that all operational decisions require an input in order to describe parameters, situations and cases. The decision logic is then executed and a result is produced.

The critical piece here is a combination of effectiveness and efficiency, especially when businesses today are challenged by rapid change and competitive pressure. Yet it is a fact that in many cases, the actual logic behind an operational decision is not at all transparent to the organization. That may be because it is buried in legacy processes and applications or embedded in the minds of subject matter experts who will inevitably move on to other pursuits in a matter of time.

The Importance of Automating Operational Decisions

All too often companies use traditional approaches in an attempt to harness operational decisions. This might involve building applications using code and low-code platforms, iBPMS and other technologies. The problem, of course, is that the operational decision becomes ‘set in stone’, as it is buried in some hard-coded application that is difficult to change. As an interim solution when change request delays occur, some may try to compensate by resorting to Excel and other spreadsheet solutions. Other business-oriented solutions like Business Rules Management Systems (BRMS), Business Process Management (BPM) and Decision Management Systems (DMS) may also come into play as companies seek to memorialise their operational decision-making processes.

The problem with these types of traditional approaches is that when these are challenged by the necessary frequency of high volume changes inherent in operational decision-making, they must be managed independently. This in turn means that decision management becomes a maintenance nightmare. In short, the organisation simply cannot keep pace with the rate of essential change to operational decisions. It is simply not enough to change one line of code or one business rule here and there while other necessary changes stay in queue until such time as someone has time to explore the deep, dark recesses of traditional systems and figure out what to do. This approach inevitably leads to less effective results.

Obviously, there is an essential need to balance the control between IT and the business by using a solution that meets the need for effective and efficient operational decision-making. That’s where FlexRule comes in. Read more about our ground-breaking solutions at www.flexrule.com.

The World of Difference between Business Rules and Business Decisions

Arash — Thu, 14 Jun 2018 11:32:00 GMT

Let me start by saying that a business rule is far more granular than a business decision, and that the two should never be confused. Today, it is an unfortunate fact that some vendors would have potential clients believe that there is synergy between business rules and business decisions. Perhaps this is because in an effort to differentiate one business rules management system from another, a zealous marketing manager decided that the word ‘decision’ rather than ‘rule’ suggested a more powerful solution to everyday business transactions.

Figure 1 – A Sample Business Rule that ensures validation of data

A Business Rule is not a Business Decision

It is true to say that the ultimate goal of both business decisions and business rules is to help the business reach a decision that enables it to run more efficiently and effectively, as well as profitably in most cases. The original concept of business rules management systems enabled end-users to craft and model an end-to-end process without the need to involve IT every step of the way. As such, a business rule was defined as one point in a detailed process of implementation, constraint handling, and data management. It could never be mistaken for a business decision, which is effectively the end point of an entire transaction.

Unlike a business rule, which is akin to a cog in a very large wheel, a business decision is something that is innately understood by a subject matter expert at a glance. It is very often also capable of recognizing and addressing exceptions to the business rules that drive the ultimate decision.

For example, a policy may be represented as a collection of business rules, but it may be better if these are modelled as a series of business decisions. In such cases, a business decision regarding whether or not to approve a customer loan, for example, would constitute a business decision based on an organizational policy which may be the outcome of the execution of a large number of business rules.

Figure 2 – A sample of a Loan Approval Decision Strategy

As business decisions exist in different levels of abstraction, they may be dependent on a complex hierarchy and sequential flow of the business rules which ultimately drive that decision. So each input to the business decision is ostensibly supported by an entire network of dependencies that are driven by business rule outcomes.

Measuring Efficiency

Unlike business decisions, business rules are not typically measured for their efficiency. There are rarely key performance indicators attributed to a business rule. In a process involving thousands of rules, this would be an exercise in futility. Rather, business rules and their impacts must be understood and modeled by subject matter experts who recognize the desired outcomes based on business decisions. It is true to say that business decisions deliver a tangible result and are related to business processes, especially when it comes to service levels. This is where KPIs typically come into play.

Figure 3 – Measuring the Performance of Business Decisions based on a KPI

The fact is that unlike a business rule, which is simply one part of what is often a very large overall ‘ruleset’ designed to affect an outcome to a particular issue, a business decision relies on supporting logic to reach a measurable operational outcome that is part of a recognised business process. In other words, a business decision is far more complex in nature than a business rule. The bottom line is that a business decision is a logical and measurable conclusion that directly impacts day-to-day business transactions, whereas a business rule is not.

Big Bucket of Rules

Arash — Tue, 13 Mar 2018 07:18:00 GMT

There are many definition of business rules and the one that I really like is that business rules are:

Criterion used to:

Guide conduct or actions.

Shape judgments of behavior.

Make decisions.

Ronald Ross

Having this definition in mind, let’s see what challenges a traditional rules management system will face when you are trying to scale. By “scaling” we do not mean the execution time in this context. I will elaborate further on that in this article.

Traditional Approach – Business Rules Oriented

In any traditional Business Rules Management System (BRMS) there is an authoring environment (i.e., a rule editor), that allows users start writing business rules. The interface presents a business rule in a few different ways, such as if-then-else statements, graphical tree, etc. You can then do things like group, tag, and label these rules for one good reason – to be able to find them. That’s because when your rule systems grow to hundreds of thousands of rules, you will feel the pain.

You need to find and group the business rules to be able to add them in a set (i.e. ruleset) for execution.
You need to be able to understand if any business rules are duplicated, or if you already have a variation of a particular rule
You need to be able to understand the potential impact if you decide to change a business rule

With this traditional approach, the reusable part of the system are the actual business rules.

Big Bucket of Rules

As a first impression, reusable business rules sound appealing. However, this conveniently innocent idea will introduce many challenges down the track. In a real system, we are talking about tens, if not hundreds of thousands of business rules all collaborating with each other to deliver value and determine an outcome.

Finding one business rule in that repository is like finding needle in a haystack! No matter how well you tag, label, group, or name each one, it is going to be hard (even nearly impossible) finding them in the repository, let alone changing a couple of them and determining the impact.
Why is this the case? Well, remember the idea of reusable business rules that we were advocating? Now you need to ensure that any change makes sense for all the other parts on which the business rules rely.

Individual business rules are very important, but often so small and granular that their reusability is of little or no value!

The picture shown above is pretty much akin to your enterprise business rules repository. Where is the piece you wanted? You also attempted to label and tag them to be found more easily when required.

Alternative – Business Decisions Oriented

Although individual business rules are important, what is more important is their ability to collaborate in order to achieve an outcome. We are more interested in the outcome – that’s why we tried to group the business rules together in the first place to achieve a desired, relevant outcome that makes business sense.

The outcomes we are after are tightly coupled to a set of Business Decisions. Consider the challenge you are trying to tackle this perspective – what business decisions are you trying to make?
When you think about it that way, your life becomes easier, simply because this question will elevate the granularity of the rules. Don’t worry about the individual business rules too soon. You need to manage the decisions rather than the business rules. The business decision becomes the module of reusability, regardless of the underlying implementation.

These business decisions are just not another type of rule sets! They are fundamentally different from mindset, approach, modeling, etc. We are going to examine business decisions in future posts in more detail.

Conclusion

If you don’t think about “business rules” in the context of the problem you are trying to solve and address, then you will not need many of things that traditional Business Rules Management Systems (BRMS) offer in the first place (e.g., Finding an orphan business rule). Traditional business rules management systems (BRMS) need those capabilities because the approach to rules are so granular and hard to manage. Think of business decisions next time and you will not find yourself in what we refer to as a ‘Big Bucket of Rules’ problem!

The Business Decisions approach has so many direct and indirect benefits like transparency of business decisions, scalability of business rules, ease of reusability and etc. These are all promises business rules management systems were not able to deliver because of their approach to rules.

** picture of the LEGO from https://www.flickr.com/photos/alanar/4444710186/in/photostream/

Quick Intro to Decision Model and Notation - DMN

Arash — Wed, 10 Aug 2016 23:03:00 GMT

Decision Model and Notation in short DMN is a novel way to model business decisions. DMN allows capturing and modeling business decisions in a way that is easy to understand with business people and subject matter experts. It is a combination of:

Decision requirement diagram – DRD
Decision table
Boxed expressions
Friendly Enough Expression Language – FEEL

Decision Requirement Diagram (DRD)

This is a graphical model that allows modeling dependencies between input data, decision, business knowledge and knowledge source.

In DRD, the arrows show the dependencies between different nodes in the model. To put it in a simple way, you can read it as if the output result of some nodes will be passed as the input of the other nodes.

In the table bellow, all the elements on a DRD model are illustrated:

ELEMENT	NOTATION	DESCRIPTION
Decision		The act of determining an output from a number of inputs, using decision logic which may reference one or more business knowledge models.
BusinessKnowledge Model		A function encapsulating business knowledge, in the form of business rules, decision table or analytic model. Some of the tool may not support this element. In such case the decision logic is directly linked to the Decision rather than the business knowledge model.
KnowledgeSource		The authority for a business knowledge model or decision.
Input Data		Information used as an input by one or more decisions. It also denotes the parameters of a Business Knowledge Model.
Information Requirement		Information – input data or decision output – required for a decision.
Knowledge Requirement		The invocation of a business knowledge model.
Authority Requirement		Showing the knowledge source of an element or the dependency of a knowledge source on input data.

Decision Table

In decision model and notation, the Decision Table is a tabular form that models rules based on conditions and actions which they are also called inputs and outputs. Decision Table is the default type of modeling business rules in DMN. But if your tools support other ways to model business rules then you can freely use them along side with decision table.

Boxed Expressions

In Decision model and notation (DMN) are a simple two column table and effective way to model business formulas, calculations, values and expressions. And then you can share them across multiple decisions and logic.

Boxed expressions simply allows modeling: constant, values, invocation, formulas… Boxed expressions allows putting together building blocks of logic (i.e. decision table, natural language, flow…) and reuse them over and over again.

Friendly Enough Expression Language

In decision model and notation, FEEL is an expression language for business people. FEEL define a syntax for expressing conditions, actions and formula. Consider FEEL like excel formulas that they allow you formulate your thinking about a domain in a context. FEEL is designed to allow ease of use by business people and subject matter experts.

Advantages

There are benefits of using decision model and notation over the traditional business rules approach. In the business rules approach, very soon you start thinking about the business rules which they are more about the logic implementation. But decision approach provides a more high-level abstracted layer that allows you to see the big picture first rather than diving deep into implementation and losing the context and overview of the solution.

This change of approach:

Allows scaling business rules in more manageable, reusable visual approach across applications and processes.
Allows better communication between business, domain experts and IT by enabling a productive involvement of business people and subject matter experts.
Allows clearly define decision boundaries and expose the decision as a service with a click!

If your tool supports simulation and execution, error checking at design time and runtime with debugging capability then you will not miss anything from business rules approach, but also will have a better way to reuse and scale your business rules in a systematic way.

Submitted by: FlexRule

Decision Model and Notation to model Business Policies

Arash — Mon, 01 Feb 2016 21:55:00 GMT

Decision model and notation (DMN) is a nice way to model policies and make sure your business rules are implemented properly. Opposite to traditional approach in business rules which was the focus on the rules them selves, in DMN we start from decisions.

Let’s work on a tangible example. In an employees benefits and entitlement system, you would have many rules, which some of them are related to calculate the employee Vacation Days. For example let’s say your company has the following policy:

Every employee receives at least 22 days. Additional days are provided to the following criteria:
1. Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days.
2. Employees with at least 30 days of service and also employees of age 60 or more, receive 3 extra days, on top of the possible additional days already given.
3. If an employee has at least 15 but less than 30 years of service, 2 extra days are give. These 2 days are also provided for employees of age 45 or more. These 2 extra days cannot be combined with the 5 extra days.

(* The policy example was provided by Prof. Jan Vanthienen)

Now let’s have a look at the bellow model:

Each of the blue rectangles are called “Decision” and each line with arrow shows the dependency of each decision to another or to an input data (employee in round rectangle with pink color).

Now we need to build couple of simple decision tables. And then associate each of them to appropriate decision node in the above decision requirement diagram.

Base days

Every employee receives at least 22 days.

Base days

Extra 3 Days rules

Employees with at least 30 days of service and also employees of age 60 or more, receive 3 extra days, on top of the possible additional days already given.

Extra 3 days vacation

Extra 5 days rules

Only employees younger than 18 or at least 60 years, or employees with at least 30 years of service will receive 5 extra days.

Extra 5 days vacation

Extra 2 Days rules

If an employee has at least 15 but less than 30 years of service, 2 extra days are give. These 2 days are also provided for employees of age 45 or more.
These 2 extra days cannot be combined with the 5 extra days. (This part is handled where we add up all the values in Total vacation days)

Extra 2 days eligibility

Total vacation days calculation

In the upper left side decision, we calculate the total days based on eligibility for base days and extra days:

Total vacation days based on other decision tables

We also set the last table aggregation method to Sum based on Rules Order. So the result will be sum of the last column (Vacation Days).

Decision model and Notation defines couple of standard aggregation functions.

Benefits of this Approach

If you model only the Decision Tables, for a slightly more complex policy you will loose the big picture and will have no clue about the whole policy not scenario that is covered. But by using the Decision Model and Notation (DMN), you start from top, and then drill down to each decision implementation (Decision tables) or other types of logic.

While Change is Certain, Business Rules are Not

ccecere — Wed, 30 Sep 2015 11:50:00 GMT

Nowhere is the need to implement and manage change more acute than within government agencies, nonprofits, and commercial businesses. Changing regulations, changing customer needs, new direction set by changing leadership, and the necessity to launch bigger, better, different products more and more quickly mean changes are inevitable. These situations not only trigger internal changes, but alter how an organization will manage its public interactions. In addition, an organization must determine how it will manage the impact of change within already established business systems and IT processes, most of which are already quite complex.

Change can trigger the need to meet tight deadlines; to update systems, forms, and websites; and to ensure understanding and acceptance across disparate constituencies, including employees, contractors, and the public. The need to change forces consideration of a variety of questions, such as:

For changes imposed upon an organization from the outside, what does compliance mean?
How will change impact an organization’s ability to achieve its goals?
How widespread is the impact of change, and how can an organization effectively prioritize addressing those impacts with the resources, time, and money available to it?

These challenges are complex. Organizational leadership and staff must understand and successfully communicate the need to change. The organization must also have capability to identify and measure the impact of the change, develop the business and technology requirements for what must change, design and implement the necessary changes, and, finally, test the modifications made to systems and processes, and validate for future operations.

Ability to change in question

While government, nonprofits, and businesses all recognize the constancy of change, few organizations are proactively prepared to address change in an organized, efficient, and effective manner. Thus, when the imperative to change occurs, most organizations are relegated to an “all hands on deck”, “man the torpedoes”, “cost is no object” strategy to address the imperative. Since the majority of change imperatives come with a deadline, the risk of disruption to an organization’s long term strategy, short term tactics, and overall health can be quite significant.

A recent survey by Robbins Gioia provides evidence that organizations are not planning for change.

A whopping 91% of respondents felt some degree of challenge when having to respond to regulatory changes, especially those with a deadline. Nearly 21% reported this to be “very challenging” for their organization.
There is also concern about losing institutional knowledge due to retirement and job changes. In fact, 91% of respondents expressed some degree of concern about this. A full 32% said they were “very concerned” about this problem.
And finally, 86% of respondents reported that they held some degree of concern about the amount of time it takes to get a new product out the door. 21% indicated that they were “very concerned” about this.

A proactive approach to managing change

The survey explored one practice in particular that, once implemented, can significantly reduce the time, cost, and risk of managing change. That practice is the capture, documentation, and tracing of business rules.

Business rules are operating principles or self-imposed constraints that apply across all operations and systems of an organization. The need for the existence of a business rule may be triggered by internal or external policies, practices or regulations. The power of capturing, documenting, and tracing business rules to the processes and systems that are impacted is significant. Business rules are:

Specific, actionable, and testable,
Independent of any one process,
Technology independent,
Under the control of the entity or organization to which they apply, and
Can be maintained in a manner to provide immediate impact analysis when a change is to occur.

Changes, particularly significant changes, affect business rules. Regulatory changes, for example, inevitably impact the business rules the guide an organization’s operations. Changes in tax laws, healthcare policies, zoning codes, and, even changes in product features and functions, will impact the rules by which a business or government entity operates.

In spite of the clear utility of understanding business rules and their applications, 93% (126 of 136) of organizations responding to the recent survey reported that their organization is challenged when it comes to capturing and maintaining business rules. In fact, 27% reported they were “very challenged” in this area.

BAs help create Invaluable Assets

If business rules describe the framework and constraints that impact an action that an organization may take, business analysts (BAs) are best equipped and positioned to help reduce organizational uncertainty — and, therefore, risk — by carefully documenting an organization's sometimes obscure processes and rules. This work can be painstaking, but a comprehensive approach helps an organization to operate more consistently, adds predictably to projects and planning, and, in the case of rapid and unanticipated change, may provide an organization a significant competitive advantage.

It would be impossible to overemphasize the value of having an organization's business rules documented and maintained by professional business analysts. To have requirements, workflows, rules, and overall process models captured in an on-going, living data and requirements repository and available for use for any effort would be invaluable. Yet, 69% of those organizations surveyed reported that they do not use a business rules repository.

Such assets and models become valuable property and tangible company assets, available to jump-start future process improvement and new product development undertakings. Such models lay the foundation for an organization's continuous optimization efforts based on solid understanding of rules, requirements, and business process models. These models provide the capability to determine that when X changes, A, B, and C are also impacted and must change as well.

Who took the survey

RG set up an online survey that got 146 responses. Of these participants, the majority was from government agencies and nonprofits, 40% (58). Others came from across private industry:

16% of respondents came from the financial world, banking, investment, and insurance
12% of respondents were from the professional services, such as accounting
Manufacturing and transportation made up 10% of respondents
High tech, telecommunications, and utilities made up 9%of respondents
The remaining respondents constituted 13% including travel and leisure, advertising, and retail.

You can take the Business Rules Survey. Find it here: https://www.surveymonkey.com/s/RGBusinessRules.

Author: Sandy Sears, PMP, CBAP, SA, PMI-PBA, is the Director, Financial Services Team, for Robbins Gioia. As a former executive at a large insurance company, she was responsible for IT process and practice development and was a key player in a large IT transformation effort, leading the rollout of project management, business analysis, and testing practices and tools across the organization, as well as the development of standardized processes for project portfolio management, IT financial management, and the SDLC. At a previous company, she was the recipient of the prestigious Chairman’s Award for her work in introducing a new annuity product line in Tokyo, Japan. She has been a speaker at industry conferences, for professional and education organizations, and on radio shows.

How To Effectively Use Observation in Projects

Fareed R — Fri, 20 Mar 2015 05:59:00 GMT

Internships can provide some great learning opportunities. I was lucky enough to learn one of the best lessons on the first day of the very first internship of mine. My mentor at the time asked that, for the first 4 weeks, I invest time in every aspect of his business to learn how everything functions. I thought he was insane yet it was one of the best lessons a college freshman could learn – by observing.

When it comes to projects, Stakeholders usually find it hard to explain what their job is or what the requirements are. So by observing and asking questions one can find out a lot more like the flow and sequence of the activities. Observing can happen passively (by quietly watching) or actively (by engaging with the stakeholder through the entire process).

The best way of capturing the activities, steps and decisions is by using a process flowchart or activity diagrams, also known as lane diagrams. Process modeling is a visual representation or the activities and swim lane diagrams shows these activities and captures the people who perform them. Each person has their own lane so it shows how the work is passed from one person to another.

When my 4 weeks were complete I fully understood how the organizational groups and processes fit into one another. How everything got together and how the products were developed, manufactured, configured and shipped.

Here is what I recently learned through observations in the designing requirement phase of a project.

Firstly define the best conceptual design while staying within the project scope and fulfill the business’ and users’ needs.
Review each step and find out what is working, what they want to keep and what they want to remove or what needs to change.
Start planning once you have all the information.

I am very grateful to my mentor for the internship experience and that, as a professional, I can now understand the value of watching people and processes in action.

More training on: https://www.udemy.com/business-analyst/?couponCode=BusinessAnalystSocialNetwork#/

Agile is an attractive word

David Wright — Mon, 29 Apr 2013 17:46:00 GMT

Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed.

The word I want to focus on from above is "external". A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enterprise: business company, non-profit group and the like. The interesting problem for most enterprises is how effectively they control their own operations. The boundary between internal and external can become nebulous if control is lacking in parts of an enterprise. Control sounds like a bad word. It implies top-down definition of all aspects of enterprise operations. This can be true, but control can also include delegation of authority, with expectation of results without definition of methods used. Control is maintained, but authority is distributed. This is the sphere of business management practices, defined and changing and transforming from Henry Ford to Jack Welch. It is not easy, and many others have and will address it better than I, so I will reference them as need be.

The topic of interest here is the boundary between internal and external, controlled and uncontrolled, event and response… but not between knowable and unknowable. An enterprise needs to know what is happening around it in order to focus its operations on knowing what events are important, events that it needs to respond to. For these events, an enterprise defines processes/procedures to execute when triggered by events, to provide the desired results in response to the events; successful enterprises include those that recognize that the nature of events and corresponding processes change over time, sometimes very quickly. So, at any one point in time, an enterprise needs to be in control of its processes, but that control can’t stifle the need to change as fast as the world around it changes. Further, this rapid change needs to be accomplished without disrupting on-going operations.

What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly to changes in its surroundings without losing its internal cohesion. The basis for controlled agility in an enterprise includes understanding that: - an enterprise runs on its processes, not its org chart - processes are composed of distinct activities and decisions - processes run on information, gathered and stored and used - processes are guided by business rules, especially when decisions need to be made. With this basis, an enterprise is well-positioned to be Agile without losing Control. It all comes down to understanding Change. Change comes in many degrees of impact to an enterprise. Consider workflow, which is based on process with roles and authority levels defined. If all loan applications over $100,000- go to Fred to be underwritten, the workflow will change temporarily when Fred goes on vacation. Those loan applications have to go to someone else until Fred gets back. This kind of change can happen frequently, but more importantly, it is a kind of change the enterprise knows can happen.

Frequent known changes are the heart of controlled agility. This is the kind of change an enterprise must be able to do, without changing itself, as part of operations. It should not need a project, especially an IT project, to make the change. Temporarily changing workflow might be considered a simple example, but it is actually an example of an overall type of change that can occur frequently, and that is business rule change. Business Rules are so embedded in how an enterprise works, it is actually a new and revealing approach to call them out separately. In a lender enterprise, it is likely a fact that “Customers may apply for Loans”, but “Customers may apply for Loans, only if they are 18 years old or older” is a Business Rule; it constrains an aspect of enterprise operations and, as said above, rules change (next year it could be 19 years). An enterprise that knows the facts and rules of their operations is well positioned to change rules as quickly as needed. However, rule changes still need to be controlled to avoid using incorrect rules to the detriment of the enterprise. Still, these changes should not require a project to change the structure of the operation and, again, not need an IT project. A major use of rules is to support making decisions. Loan underwriting across many financial lending/leasing enterprises is heavily rule-driven, the information about a customer and the loan product being used to decide to lend or not. These can be complex rules, or simply that the enterprise does not lend to anyone with a Credit Score below a stated value; and again, the rules will be changed over time as a lender tunes its underwriting, or is willing to take on more risk, etc..

Decisions also play a role in defining what processes/activities are used to respond to events. We all know of BPM diagrams with boxes for activities, diamonds for decision points, and arrowed lines connecting them all. A process may be composed of 20 possible activities, but less than 20 might be used in response to any one event because of decisions based on rules. What can change for a process? The number of processes in an enterprise, once all are defined, is relatively stable over time; new processes usually mean the enterprise has expanded its products/services to areas which need their own processes. Within a process, however, the exact activities that are carried out may change, or be re-ordered, or even be retired. It is the ability to change processes as quickly as possible, again without a project, that marks an enterprise as Agile. Changes in decisions and rules used in processes are the most frequent changes an Enterprise must do. Changes to the activities in a process change less frequently than decisions/rules, but often enough the agile enterprise needs to it as part of its operations. Are there aspects of an enterprise that are more stable? And are types of changes to them not necessarily known or predictable? This is a loaded question, because the answer is information or specific data used by an enterprise. Once all the information needs are known for an enterprise, these are very stable over time. The need to change information needs is similar to the need to add more processes; it happens when (as above) the enterprise is expanding into new products or services different from current products/services. To be more precise, information needs may change as the enterprise expands, but they may not as well; data requirements have been shown to be the most stable aspect of an enterprise.

So we have two ends of the change pendulum: from frequent and known, to rare and unknown. As said earlier, frequent known changes are the heart of controlled agility.

Business rules are a backward step

Dr David Fletcher — Fri, 13 May 2011 09:04:00 GMT

I have been delivering projects successfully since the early 80s. Back then, we didn't have business rules, we had formal logical data models, entity life histories, data constraints, and data flow diagrams. In general, all the necessary business constraints got captured properly and implemented. Some of these deliveries actually passed acceptance testing with no defects.

Since then I have joined a company which does use-case driven development, and in the use cases there is a section for 'Business Rules'. Logical data modelling is rarely done, and life-history modelling is almost never done. Business constraints are now frequently missed and contradictions are not detected or poorly understood. Having read many hundreds of such rules by now, I conclude that they mostly consist of data constraints which ought to be in a data model, event processing constraints which ought to be in an entity life history, or security and audit constraints which might actually legitimately belong in a rules catalogue (the latter are the rarest category).

From this I conclude that the concept of a business rule is too vague, and business rules are often an excuse to avoid doing thorough modelling. As Ivar Jacobsen once said 'if you have not modelled it, you have not understood the problem".

Challenges with User Stories

Seilevel — Mon, 22 Nov 2010 17:44:00 GMT

A Promise to have a Conversation

I’ve been writing user stories for a couple of years now, and the best way I’ve heard how to describe them is that they are a promise to have a conversation. Enough information should be written down to give the reader an idea of what the gist of the story is (and to be able to roughly estimate a story point size to it), but the details are to be driven out during discussions between the product owner and the development team at the start of the sprint.

And that concept works well when the product owner and the development team are located in the same location. As a product owner, I could attend the daily scrum meetings; I was available to the developers/testers/technical writers to answer questions as they arose.

Recently, however, I’m working on a project where the development team is not located with the product owners. In fact, development may be done in several different locations around the world. This introduces several layers of complexity that a co-located team does not have. Not only is there distance differences between the various team members, but now we also introduce time zone, language and cultural differences as well. As a result, there is a greater documentation requirement than I have had to deal with before. While the promise to have a conversation still holds, the product owner is just not as available with a geographically diverse team.

Story Size – Large vs. Small

So one of the first hurdles to jump was what the appropriate size of the user story is. I’ve had some interesting conversations with various people about this topic, and opinions do vary. Some feel that user stories should tell an end-to-end story. But that can result in very large, very complex user stories. I do see value in these user stories, and I tend to call them epic stories. I prefer to take these epic stories and break them down into much smaller user stories.

One characteristic I try to keep in mind as I write a user story is that it should be small enough to be developed during one sprint. So it is critical to understand the size of the sprints within your organization, since I’ve heard of sprints lasting anywhere from 1 to 6 weeks. It also helps to get your development organization to provide you with some rough story point sizes, so you know if your stories are of an appropriate size or not. For any story that has a point size estimate that is larger than the velocity of the team during a sprint, that story needs to be broken down into smaller stories.

What to do with Business Rules?

Another challenge is business rules. With the project that I am working on, we have finished documenting the user stories, but they only tell part of the story. They tell what the user expects to see, but not how the system gets to those results. That is the role of the business rules.

Now, if the team were co-located in the same location, this is where the promise to have a conversation would come in. During that conversation, the business rules can be vetted and discussed. However, with the geographically dispersed team, much of this needs to be written down. The story and the business rules can still be discussed, however, with cultural and language differences, having something in writing for team members to read through before the discussion and to refer back to after the discussion is a necessity.

But what is the best way to document these business rules? Some can be documented with the acceptance criteria for the user story. But sometimes there is the additional needs to get even more detailed than that, to get to the actual “if, then” statements. Where is it best to document them? I don’t have an answer to that yet, and much may depend upon the tool chosen to store the user stories.

But I am certainly interested in your experiences…how have you solved this problem?

Let us know, or check out other posts. http://requirements.seilevel.com/blog/2010/10/challenges-with-user-stories.html

How do you determine if you have a business rule?

Seilevel — Fri, 23 Jul 2010 14:09:00 GMT

On a recent client’s project, we were asked to help in the effort of creating a system to automate much of the current manual processes. In order to capture the requirements this also meant that we were documenting the business rules that were currently being used. When I started the project, I did not have a complete understanding of how a business rule was different than a requirement statement. I found that I was constantly getting mired in my confusion between the two.

From my research I did find one Wikipedia article to be particularly helpful, but I simplified that advice even further. From my reading and experiences, I created the following four guidelines to help me determine if a statement was a business rule that would need to be represented within the new system and should described within my functional requirement statements.

1: A business rule is about the how to run the business and not about a system, or set of systems. If you removed all the systems and system platforms, the rule would still important to the business operations. Business rules are about people doing business activities, to achieve business goals not interacting with systems. A very simple rule that is used every day is “No shoes, no shirt, no service” a person can read this rule, and know what actions they are to perform. A functional requirement would be to support the “No shoes, no shirt, no service” rule within the system.

2: Does the rule provide enough information for a business person to make a decision, or a series of decisions? If a business person uses the rule to make a decision, then it’s a business rule. The rule exists in order to operate the business. A business person could easily read the rule and understand how they are to conduct business.

3: Business rules are owned by the business. A business person must be able to change, or modify rules as they identify changes. For example, a rule may be that “Only people between the ages of 25-35 may open a customer account”. A system requirement could be written to support that age constraint. The rule however, is owned by the business and could be changed at any time based on business objectives.

4: A business rule must place some type of constraint or requirement on the way that business is conducted. For example, “Only customers with an approved line of credit of $1,000 or more may place orders within the corporate product catalog”. This rule shows how customers are constrained and prevented from certain operation, or activities. A system requirement might be necessary to support multiple rules which constrain customer activities. The business rules define the constraints.

by LAnderson

Do you have feedback on how to determine a business rule?